home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 521 < prev    next >
Encoding:
Text File  |  1996-08-06  |  2.3 KB  |  55 lines
  1. Path: newshost.lanl.gov!tanmoy
  2. From: tanmoy@qcd.lanl.gov (Tanmoy Bhattacharya)
  3. Newsgroups: comp.std.c
  4. Subject: Re: Array vs. structure alignment
  5. Date: 05 Mar 1996 14:13:17 GMT
  6. Organization: Los Alamos National Laboratory
  7. Distribution: world
  8. Message-ID: <TANMOY.96Mar5071317@qcd.lanl.gov>
  9. References: <1996Mar5.114346.1790@ittpub>
  10. NNTP-Posting-Host: qcd.lanl.gov
  11. Mime-Version: 1.0
  12. Content-Type: text
  13. In-reply-to: wil@ittpub.nl's message of 5 Mar 96 11:43:46 WET
  14.  
  15. In article <1996Mar5.114346.1790@ittpub>
  16. wil@ittpub.nl (Wil Evers) writes:
  17. <snip>
  18. WE: 1. Is there any technical reason why the memory layouts of CUSTOMER_TYPE  
  19. WE: and PROPER_CUSTOMER_TYPE would be different? It seems to me that wrapping  
  20. WE: an array into a structure is something relevant at compile-time, not at  
  21. WE: run time. IMHO the generated code for accessing the fields in a  
  22. WE: CUSTOMER_TYPE could be exactly the same as the code for accessing the  
  23. WE: fields in a PROPER_CUSTOMER_TYPE.
  24.  
  25. Because the easiest implementations need the representation of all
  26. struct types to be identical, maybe your compiler is trying to enforce
  27. their alignment as identical too? Why? You don't seem to be on a
  28. machine where the generation of an unaligned pointer (rather than its
  29. dereference) will create a hardware fault. 
  30.  
  31. But, in any case, wrapping an array in a struct may introduce padding
  32. at the end.
  33.  
  34. WE:  
  35. WE: 2. Assuming there is no technical reason for this difference, shouldn't  
  36. WE: the C standard require that the layouts of these two types be the same?  
  37. WE: [Please don't ask me for an exact phrasing - I'll happily leave that to  
  38. WE: the experts.]
  39.  
  40. The C standards committee has been very unwilling to put absolutely
  41. any limits on the implementation decision to introduce padding. I do
  42. believe that a quality implementation should provide a pragma
  43. (yecchhh)/compiler switch to pack structs: but that has little to do
  44. with comp.std.c
  45.  
  46. Cheers
  47. Tanmoy
  48. --
  49. tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
  50. Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
  51. Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
  52. <http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
  53. internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
  54. fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]
  55.